\chapter{State of the Art}
\label{chap:state_art}

\epigraph{``\textit{Computer science is no more about computers than astronomy is
about telescopes.}''}{Edsger W. Dijkstra}
 
Service oriented computing is at the origin of an evolution
in the field of software development. An important challenge
of service oriented development is to ensure the alignment
between IT systems and the business logic. Thus, organizations
are seeking for mechanisms to deal with the gap between
the systems developed and business needs. The literature
stresses the need for methodologies and techniques for
service oriented analysis and design, claiming that they are
the cornerstone in the development of meaningful services'
based applications. In this context, some authors argue
that the convergence of model-driven software development,
service orientation and better techniques for documenting and
improving business processes are the key to make real the idea
of rapid, accurate development of software that serves, rather
than dictates, software users' goals \cite{BichlerL06}.
 
Service oriented development methodologies providing
models, best practices, and reference architectures to build services' based
applications mainly address functional aspects. Non-functional aspects concerning
services' and application's ``semantics'', often expressed as
requirements and constraints,
are not fully considered or they are added once the
application has been implemented in order to ensure some
level of reliability (e.g., data privacy, exception handling,
atomicity, data persistence). This leads to services' based
applications that are partially specified and that are thereby
partially compliant with application requirements. 

In systems' and requirements' engineering, a non-functional
requirement (NFR) specifies criteria about the operation of a
system. Non-functional requirements are often called
qualities of a system. Other terms for non-functional requirements are
``constraints'', ``quality attributes'', ``quality goals'', ``quality of service
requirements'' and ``non-behavioral requirements'' \cite{Stellman2005}. NFR's
should be contrasted with functional requirements that define specific behavior
or functions of a system.

Non-functional requirements are related to business process associated to the
behaviour of the application and in the case of services' based
applications, they also concern the constraints imposed by the services. The
plan for implementing functional requirements is detailed in the system design.
The plan for implementing non-functional requirements is detailed in the system
architecture. Programming non-functional properties is not an easy task and
different recent studies
\cite{Babamir2010,AgarwalLS09,CholletL09,GutierrezRF10,XiaoCZBOLH08,JeongCL09} try to
associate non-functional requirements and services in different ways and using
different approaches. Associate non-functional requirements to services
composition can help to ensure that the resulting application is compliant to
the user requirements and also with the characteristics of the services it uses.
As services are independent components, ensure non-functional properties is a
challenge in developing this type of application. To adapt quality properties in
the web service development context can provide a greater software reuse.


 Attempts to solve these problems have led to the appearance of a great deal of
 work in non-functional attributes and non-functional requirements. Although
 they are used as synonyms in most NFR approaches, we will distinguish the
 concepts of non-functional requirements and non-functional attributes.
 NFRs are a group of semantically correlated
 non-functional attributes (NFA). For example, \textit{security} is an
 non-functional requirement that comprises attributes such as
 \textit{confidentiality} and \textit{integrity}, and a non-functional
 attribute describes the characteristics of a functional requirement. 
 
 Based on this context, this chapter presents \textit{(i)} the state of the art
 of web service based methodologies and non-functional requirements for web
 service based applications, and \textit{(ii)} analyses the principal methodology
 concepts for web service development. The works will be analysed in order to discover the
 different existing concepts, proposals, problems and solutions related with
 each area.
 
% The goal of this chapter is presents, based the concepts obtained from
% non-functional requirements and software engineering methodologies' works,
% a systematic analysis concerning \textit{(i) a towards NFR
% classification for reliable web service development, (ii) its application on the modeling web services composition and
% (iii) how to apply these set of concepts through a proposal for a reliable web
% service based methodology development}. 
 
The analysis of the NFR and software engineering methodology for web
 services will be conducted through a systematic review on these two concepts.
 ``\textit{A systematic review provides means of identifying,
 evaluating, and interpreting the literature relevant to a particular research
 question or topic area}'' \cite{Kitchenham08}. The result of this review
 can be useful for summarize the existing evidence concerning a treatment or
 technology, identify gaps in current research in order to suggest areas for
 further investigation, and provide a background to new research activities.
 Nevertheless, our goal is to identify a common nomenclature for existing NFR
 and web service based methodology and propose a specification of these concepts
 in the context of reliable web services development. 
 
 This chapter is organized as following. Section \ref{sec:nfrs} presents the
 main concepts and works related with non-functional requirements for web service
 application, its analysis and most important notations. Section
 \ref{sec:metodologies} presents the main concepts and works related 
 with methodologies for web service development, its analysis and standard
 notations. Section \ref{sec:stateofart_conclusion} presents the conclusions of
 this chapter.


% The remainder of the Chapter is structured as follows: Apendix
% \ref{append:systematic_literature_review} shows what is an
% SLR is and describes the strategy's analisys for the state of the art's
% related works. The results of the SLR are analyzed in Section
% \ref{sec:results_systematic_literature_review}. We present the NFR meta-model
% and its application on reliable service modeling, and a proposal of NFR
% classification for reliable web service development in Section
% \ref{sec:proposal}. Finally our conclusions.
   

\section{Non-Functional Requirements for Service-Based Applications}   
\label{sec:nfrs}   

This section presents the state of the art of the non-functional
requirements and properties used in the context of service-oriented
development. The purpose of our analysis is to identify the concepts,
properties and notations used in the service-based systems development, and
find if there is any pattern or relationship between non-functional
requirement concepts in different modeling levels. In the systems development,
for each phase, the requirements and non-functional requirements are being
refined and the granularity becomes thinner after each iteration. The focus of a
modeling-based non-functional requirements becomes important because it reveals
a continuing need on the development of distributed service-oriented. Thus, it
is necessary identify how non-functional requirements are classified in
different development process phases and iterations.

% Thus, this section also presents the collected data and results
% from the research work analysis according to some research questions. Once the
% sources' extraction execution had been completed, it was important to be sure
% that multiple publications of the same approach were not included in the data analysis. Tables \ref{tab:result02}
% and \ref{tab:result03} show the results of each work under each question
% described in section \ref{subsec:question}.  





% % Among the properties presented we highlight the security
% % and performance properties. All users want to access data
% % securely and quickly. Most studies analyzed have both properties. Reliability is
% % also an important non-functional requirement presented in some papers and needed
% % to end users. 

% 
% The analisys was carried out by effectuating the following activities:
% \textit{(i) question formulation; (ii) source selection; (iii) selection
% process; (iv) information extraction;} and \textit{(v) results}.

We defined 7 research questions to guide our analyses about non-functional
requirements. The questions are closely related to service-oriented
development with a NFR focus. They are:
  
\begin{itemize} 
  \item \textbf{\texttt{$RQ_1$:}} How NFR are modeled in existing methodologies
  for developing reliable web services?
  \begin{itemize}
	  \item \textit{definition concepts}
	\end{itemize}  
 \item \textbf{\texttt{$RQ_2$:}} Which are the NFR that are more frequently
 considered in methodologies developing web services?
 	\begin{itemize}
	  \item \textit{security / availability / portability / \ldots / reliability /
	  performance}
	\end{itemize}
  \item \textbf{\texttt{$RQ_3$:}} What is the software
  development approach used in the paper?
	\begin{itemize}
	  \item \textit{Model driven approach (*MDD) / Ontology (*Ont) / Formal method
	  (*FM) / Artificial intelligence (*AI) / Business Process Modeling (*BP)
	  Traditional (*TDT)}
	\end{itemize} 
  \item \textbf{\texttt{$RQ_4$:}} What is the discipline (application domain)
  of the ``\textit{non-functional requirements}'' / ``\textit{non-functional
  properties}'' used in the work?
  \begin{itemize}
	  \item \textit{Software architecture / QoS model / Language definition /
	  Methodology / etc}
	\end{itemize}	
  \item \textbf{\texttt{$RQ_5$:}} Does the paper proposes a (meta)model
  describing and analyzing NFR? Is there any relationship between
  the non-functional requirements (meta)model proposed and business services? 
\begin{itemize}
	  \item \textit{yes / no} -- \textit{yes / no}
	\end{itemize}  
  \item \textbf{\texttt{$RQ_6$:}} Do the non-functional aspects are treated in
  an independent way or do they include the service compositions modeling?
\begin{itemize}
	  \item \textit{single / composition}
	\end{itemize}
\item \textbf{\texttt{$RQ_7$:}} Which is the publication year of the paper?
	\begin{itemize}
	  \item \textit{Year of publication}
	\end{itemize}	   
\end{itemize}


% \subsection{Source Analysis}
% \label{subsec:souce_analysis}

In the development of systems, for each phase of development,
the requirements are being refined and the granularity becomes tiner after each
iteration. With the analysis, we can identify how these NFRs have been
classified.

% The focus of a modeling based on non-functional requirements becomes important
% because it reveals a continuing need on the development of distributed
% service-oriented. Among the properties presented we highlight the security
% and performance properties. All users want to access data
% securely and quickly. Most studies analyzed have both properties. Reliability is
% also an important non-functional requirement presented in some papers and needed
% to end users.
 
% Based on the first research question, the results were the most different
% possible. Despite being different, the nomenclatures in each paper  most often are
% associated to the same concept. The question was, ``\textit{How NFR are modeled
% in existing methodologies for reliable web services development?}'' We will
% highlight the nomenclature used for each work.

 
\subsection{Concepts and Works}
\label{subsec:nfr_concepts}

We used the approach described in Appendix \ref{append:analysis} to the search, collection and
selection of works related with non-functional requirements for developing
service-based applications. Based on these data we analyzed concepts were used
in each work for the description of NFRs and the difference between them. The
notation used to refer non-functional requirements will be highlighted in
\textit{italic}, as well as the set of values that can be associated with each
concept. For example, a notation used by a work can be \textit{quality property}
or \textit{non-functional concern}, and the values associated with
its notation are \textit{security}, \textit{reliability}, \textit{transaction}
and etc. 	

\bigskip
\bigskip

Babamir et al. \cite{Babamir2010} ranks services \textit{quality properties}
in three categories (business level, service level, system level). The
\textit{quality properties} are associated with \textit{quality constraints},
that are defined as assertions or propositional logic expressions. \textit{Non-functional attributes,
composition model entity} and \textit{model entity} are the notations used by
Xiao et al. \cite{XiaoCZBOLH08} for classifying the different concepts for
non-functional requirements modeling. Non-functional attributes (NFAs) describe
the non-function aspects in the abstract process models. The framework to
model NFRs proposes to annotate composition models with NFAs.

D'Ambrogio \cite{DAmbrogio06} uses the notation \textit{quality characteristics}
to group similar characteristics in \textit{quality categories}. Each
\textit{quality characteristic} is quantified into  \textit{quality dimensions}. \textit{Quality characteristic} is
a quantified QoS aspect, for example \textit{latency, throughput, reliability,
availability}, etc. \textit{Quality characteristic} of a common
subject are grouped in abstract \textit{quality categories}, for example
\textit{performance} (for latency and throughput characteristics) and
\textit{dependability} (for reliability and availability characteristics).  
 
The notation \textit{category, sub-category}
and \textit{property} to classify non-functional requirements are used by Yeom
et al. \cite{Yeom2006}. \textit{Business},
\textit{service} and \textit{system} are the possible values to be associated
with; a \textit{sub-category} can be \textit{security, value, interoperability},
etc. The work defines a \textit{web services quality model}, which considers non-functional properties in different
aspects. In this model, web services qualities are classified in categories and
sub-categories. Similarly, Chollet et al. \cite{CholletL09} uses only 2 terms to
classify and relate quality properties with services, they are:
\textit{activity} and \textit{quality property}. Each activity represents a
functional property that can be divided in sub-activities, depending on the
activity granularity. For non-functional requirements, the work describes the
possibility of creating different meta-models for each \textit{quality
property}, and thus relate them with activities.


Schmeling et al. \cite{SchmelingCM11} uses the 
\textit{non-functional concerns (NFC)} notation to describe NFRs. This support
encompasses two aspects: the specification of NFCs and their realization. \cite{SchmelingCM11} details that a \textit{functional
concern (FC)} is a coherent piece of functionality that
is part of a software system, for example a book flight concern
for a travel application which can be described by a use
case. \textit{Non-functional concern (NFC)} is a
general term describing a matter of interest or importance that does
not correspond to a functional but rather a non-functional
requirement pertaining to a system, for example, \textit{security, reliability,
transactional behavior}, etc. A \textit{non-functional action} is
another notation used, which represents behavior that results in 
a \textit{non-functional attribute}. An example for an \textit{non-functional
action} is \textit{encryption}, which realizes the \textit{non-functional attribute},
\textit{confidentiality}. A \textit{non-functional activity} is also used as a
term, which means encapsulate the control flow of \textit{non-functional
action} that apply to the same subject. The term is used in analogy to activity
and action in UML2.

Ceri et al. \cite{CeriDMF07} utilizes \textit{policy, rule, condition} and
\textit{action model} to specify NFRs, and in a similar way, Agarwal et al.
\cite{AgarwalLS09} also uses the concept of \textit{service policy} associated with the concept of service.
A \textit{service} may have \textit{policies}. Each service is also associated
with a \textit{service property}, which may have a specific value (\textit{security,
reliability}, and so on). Each service is also associated with a \textit{unit
function} of application, that represents one or more requirements. 

Ovaska et al. \cite{OvaskaEHPA10} uses
\textit{quality attribute, category, conceptual layer} and \textit{importance}
concepts to organize and classify the NFRs, while Pastrana et al.
\cite{PastranaPK11} uses the \textit{contract} notation to describe non-functional requirements. In a
\textit{contract} it is possible to define pre-conditions, post-conditions and
invariants. A \textit{web service} can have many \textit{contracts}, that
defines many \textit{assertions} and are associated with \textit{quality
properties}.




Some works do not have any
nomenclature to classify non-functional requirements. Some uses the
\textit{attribute} notation \cite{ZhangPSP05,BasinDL06,JeongCL09}, other
uses \textit{properties} \cite{Fabra2011}, other \textit{factors}
\cite{MohantyRP10,GutierrezRF10}, \textit{characteristics}
\cite{DiamadopoulouMPS08}, \textit{quality level} \cite{ModicaTV09} or
\textit{values} \cite{ThissenW06,BasinDL06}. However, none of them present a
specific notation or model to sort the non-functional requirements.


\subsection{Analysis}
\label{sec:proposal}

The purpose of this analysis is to identify the properties and non-functional
requirements used in the development of systems, and see if there is any pattern
or relationship between non-functional concepts in different
modeling levels.

Although many different types of notation used for sorting non-functional
requirements, in general, the values are the same, \textit{i.e.}
\textit{security, performance, reliability, usability, availability}, etc. What
distinguishes the different approaches are the adoption of a NFR hierarchy,
trying to prioritize or classify the quality requirements. This is due to
different application contexts and approaches used. Another interesting factor
is that the each work uses different approaches to model these requirements.
Because of this, there are different kinds of notations for non-functional
requirements.
 
Most works use
\cite{DAmbrogio06,CholletL09,SchmelingCM11,BasinDL06,Fabra2011,OvaskaEHPA10} MDD
(Model Driven Development) for system design and development. Among them, only
Fabra \textit{et al.} \cite{Fabra2011} presents a complete methodology, however
spite of using quality requirements in their case study. The modeling is not mainly
focused on non-functional requirements. Fabra \textit{et al.} \cite{Fabra2011}
also describes the importance of the use of MDD in the development of
service-oriented applications. \cite{ThissenW06,ZhangPSP05} uses formal method
for development based on NFR for web services, \cite{AgarwalLS09,PastranaPK11} use ontology
approach for the definitions and modeling of non-functional requirements and
\cite{XiaoCZBOLH08,GutierrezRF10} use Business Process Modeling (BPM) for
system specification, including NFR. Most works focus on composition
service modeling and half of the work defined requirements models to
represent the properties used.

In \cite{Babamir2010,Yeom2006} the non-functional properties for web services
are classified into three categories such as
\textit{service-level view ,system-level view} and \textit{business-level view}.
In the \textit{\textit{business-level}} the quality properties are:
\textit{service charge, compensation rate, penalty rate} and
\textit{reputation}; in the \textit{\textit{service-level}} the quality
properties are: \textit{performance} and \textit{stability}; and in the
\textit{\textit{system-level}} the quality properties are classified in:
\textit{manageability, interoperability, business processing} and
\textit{security}. The system level properties has already more refinement
properties related with these ones that were presented.

For \cite{XiaoCZBOLH08}, each task in the process model is annotated
with the NFAs (\textit{non-functional attributes}). During the design phase, the
service composition process and the definition of NFAs are made separated. Then,
each task in the process model is annotated with the corresponded NFA. The
attributes are related with task or data. For data, the NFAs are:
\textit{value} and \textit{range}; and for task the NFAs are: \textit{cost,
time, resources} and \textit{expression}.

D'Ambrogio \cite{DAmbrogio06} presents a WSDL extension for describing the QoS
of web services. The process is MDA-based. The work presents a catalog of \textit{QoS
characteristics} for the web services domain and a Q-WSDL (Quality WSDL)
meta-model for modeling QoS properties in web services. The main properties
presented are: \textit{availability, reliability} and \textit{access control}.
Each property has different attributes that composes the property concept.
\cite{CholletL09} presents a security meta-model for web service composition.
The non-functional requirements considered in the work are related with
\textit{authentication, integrity} and \textit{confidentiality}. Each property
is related with a service activity. \cite{SchmelingCM11} presents an approach
and a toolset for the specification and realization of the composition of
multiple non-functional properties in web services. The main non-functional
attributes described in the work are: \textit{confidentiality, integrity
(security concern)} and \textit{response time (performance concern)}.

The work presented in \cite{ThissenW06} describes some interesting
steps to design a selection mechanism of service candidates in a composition,
considering quality properties. The steps are: \textit{(ii)} identification of relevant QoS
information; \textit{(ii)} identification of basic composition patterns and
QoS aggregation rules for these patterns; and \textit{(iii)} definition of a
selection mechanism of service candidates. As QoS information assigned with each basic
service, the following were chosen: \textit{performance, cost, reliability} and
\textit{availability}. 
  
We highlight the following works: \cite{CeriDMF07,
Yeom2006,JeongCL09,PastranaPK11}. These research works present a relevant
detail of some NFR and a good detail of them in each stage of development.

Among the properties presented we highlight the \textit{security}
and \textit{performance} properties. All users want to access data
securely and quickly. Most studies analyzed have both properties as the most
important non-functional requirements. \textit{Reliability} is also an important
non-functional requirement presented in some works and required to end users.

Considering the research questions presented in section \ref{sec:nfrs}, the
works described in section \ref{subsec:nfr_concepts} and our analysis, tables
\ref{tab:result02} and \ref{tab:result03} show some collected results.

Despite many different types of NFR notation used
in these works, there is still no clear classification of NFRs
and a hierarchy or dependency between them. Only 5 of the works present a hierarchy
among the different non-functional requirement notations, representing only
1.6\% of the total (over 306 works) and 26.31\% of total of works chosen (over
19 works) (see Appendix \ref{append:analysis}). This hierarchy is used according to the
modeling level and process phase. 

% Among these works, we highlight
% \cite{Yeom2006,DAmbrogio06,CeriDMF07}, because it presents the types of NFR and
% their importance at each modeling level.

  
\begin{table}[ht!]
\centering
\scriptsize
\begin{tabular}{l|l|l|l|l}
  \hline 
  \hline
   \textbf{Reference} & \textbf{\textit{NFR concepts}} &
   \textbf{\textit{NFR values}} & \textbf{\textit{Approach}} &
   \textbf{\textit{Domain / Scope}} 
   \\
  \hline
  \hline  
  Babamir et al. \cite{Babamir2010} &  property / & responsiveness /
  availability   & TDT & Software architecture
 \\  
  & category /  & performance / sla properties   &  & 
 \\
 &  constraint &    &  & 
 \\ 
  \hline   
 
  Yeom et al. \cite{Yeom2006} & category / & business value / performance /
   & TDT & QoS model\\ 
   & sub-category / & stability /manageability /   & & \\
   & property & security / business processing  & & \\
    &  & interoperability & & \\ 
  \hline 
  
  Xiao et al. \cite{XiaoCZBOLH08} &  NF attribute  & time /
cost / resource  & BP  & Business processes
   \\
 	&   &   &  & modeling
   \\   
  \hline 
  D'Ambrogio \cite{DAmbrogio06} &  characteristics /  & availability /
  reliability / & MDD & WSDL \\ &  category /  &  access control  &  &
  extension
  \\
  &  dimension &    &  & 
 \\
   \hline
  Chollet et al. \cite{CholletL09} & activity / & security  & MDD 
  & Orchestration Framework
   \\
  &  NF attribute &    &  & 
  \\
  
  \hline
  Schmeling et al. \cite{SchmelingCM11} & NF concern / & security &
  MDD &  Web service 
  \\
  & NF attribute / &  &
   & composition process
    \\
  &  NF action / &    &  &
   \\
  &  NF activity	 &    &  &
  \\ 
  \hline
    Thi{\ss}en et al. \cite{ThissenW06} & NF value  &  performance /
  reliability &  FM & Software architecture \\  
   & & cost / availability &  & \\  
  \hline
  Zhang et al. \cite{ZhangPSP05} & attribute /& security & FM &  Access control 
   \\
  &  predicate &    &  &
  \\
  
  \hline
  Basin et al. \cite{BasinDL06} &  attribute & security  & MDD & System
  architecture
  \\
  \hline
  Ceri et al. \cite{CeriDMF07} & police / rule  & n.a. & TDT & Context-aware
  applications
   \\
  &  condition / action &    &  &
  
  \\
  \hline
  Fabra et al. \cite{Fabra2011} & property & storage /
  processing & MDD & Web service methodology 
  \\
   &   & (*case study) &  & 
  \\
  \hline
  Modica et al. \cite{ModicaTV09} & quality level & sla
  properties & TDT &  Service oriented 
  \\
   &  &  &  & architecture \\
  \hline
  Ovaska et al. \cite{OvaskaEHPA10} & attribute & security / reliability
  & MDD &  Model development
  \\
   
  &  category &    &  &
  \\
  \hline
  Agarwa et al. \cite{AgarwalLS09} & property / & \textit{not explicitly
  defined} & Ont & Policy language
  \\
   
  &  policy / &    &  &
  \\
  
  &  function &    &  &
  \\
  \hline
   &  & operation cost /&  &  \\
  &  & performance / availability /  &  &  \\
  Jeong et al. \cite{JeongCL09} & NF attribute & accessibility / security /
  & AI  & Service oriented   \\ 
   &  &
  interoperability / usability / & & \\ &  & user satisfaction &  & architecture
  \\
  \hline
   &  & performance / reliability /  &  & \\
   & NF property / & scalability / capacity /&  & \\
  Pastrana et al. \cite{PastranaPK11} & contract  / & robustness /
  precision / & Ont & Web service methodology\\
  & assertion / & accessibility
  / availability / &  & \\ 
   & NF behaviour & interoperability / security  &  & \\    
  \hline
  Diamadopoulou et al. \cite{DiamadopoulouMPS08} & NF characteristic &
  user' subjective & TDT & Web service selection  \\ 
   &  & perception  & &  \\
  \hline
  Gutierrez et al. \cite{GutierrezRF10} & NF factor & Security  & BP &  Web
  service
  \\
   &  NF sub-factor&   &  &  development process
  \\  
  \hline
  Mohanty et al. \cite{MohantyRP10} & NF attribute or & reliability /
  performance / & & Artificial intelligent /\\ 
  & NF factor & integrity / usability  & AI  & Web services classification	 \\
  &  & response time / documentation &   &  \\
  
  \hline  
  \hline  
\end{tabular} 
\caption{Research question results - $RQ_1$, $RQ_2$, $RQ_3$, $RQ_4$.}
\label{tab:result02}
\end{table} 
 
\begin{table}[ht!]
\centering
\scriptsize
\begin{tabular}{l|l|l|l}
  \hline 
  \hline
   \textbf{Reference} & \textbf{\textit{Service model}} --
   \textbf{\textit{Business services}} & \textbf{\textit{Service type}}  &
   \textbf{\textit{Year of publication}} 
   \\
  \hline
  \hline  
  Babamir et al. \cite{Babamir2010} & no -- yes  & composition & 2010   
 \\  
  \hline   
  Yeom et al. \cite{Yeom2006} & yes -- yes & single   & 2006  \\  \hline
  Xiao et al. \cite{XiaoCZBOLH08} & no -- no & composition    & 2008
   \\ 
  \hline 
  D'Ambrogio \cite{DAmbrogio06} & yes  -- no & composition  & 2006 \\
   \hline
  Chollet et al. \cite{CholletL09} & yes -- yes & composition  &  2009 \\
  \hline 
  Schmeling et al. \cite{SchmelingCM11} & no -- no & composition &  2011 \\ 
  \hline
   Thi{\ss}en et al. \cite{ThissenW06} & no -- yes & composition & 2006
   \\
  \hline
  Zhang et al. \cite{ZhangPSP05} & no -- no  & single  & 2005 \\ 
  \hline
  Basin et al. \cite{BasinDL06} & yes -- no & single / composition  & 
  2006\\
  \hline 
  Ceri et al. \cite{CeriDMF07} & no -- no  & single  &  2007\\ 
  \hline 
  Fabra et al. \cite{Fabra2011} & yes -- yes & composition  &  2011\\
  \hline
  Modica et al. \cite{ModicaTV09} & no -- no & composition & 2009\\ 
  \hline
  Ovaska et al. \cite{OvaskaEHPA10} & yes -- no & single & 2010\\
  \hline
  Agarwa et al. \cite{AgarwalLS09} & yes -- no & single / composition  &  
  2009\\
  \hline
  Jeong et al. \cite{JeongCL09} & no -- no  & composition &  2009\\
  \hline
  Pastrana et al. \cite{PastranaPK11} & yes -- no & composition &  2011 \\
  \hline
  Diamadopoulou et al. \cite{DiamadopoulouMPS08} & no -- no & composition 
  & 2008\\
  \hline
  Gutierrez et al. \cite{GutierrezRF10} & no -- no &  single / composition 
  & 2010\\
  \hline
  Mohanty et al. \cite{MohantyRP10} & no -- no  & single  & 2010\\
  \hline
  \hline  
\end{tabular}
\caption{Research question results - $RQ_5$, $RQ_6$, $RQ_7$.}
\label{tab:result03}
\end{table} 

There are other works
\cite{ieee_1998,CysneirosLN01,Cleland-HuangSZS06,Glinz05rethinkingthe,sommerville08}
that consider and propose a non-functional requirements classification for
service based application development. There are a number of software
attributes that are defined as requirements \cite{sommerville08,ieee_1998}. It is important that
required attributes are specified so that its performance can be objectively
verified. According to \cite{ieee_1998}, the main non-functional properties are:
\textit{performance}; interface; operational; resource; verification;
acceptance; \textit{maintainability}; documentation; \textit{security};
\textit{portability}; quality; \textit{reliability}; \textit{usability}; and 
\textit{safety}. Some were highlighted, because they are the most frequently
presented in the classification of requirements services. This NFR specification
also proposes a template for system requirements specification, considering
both, functional and non-functional properties.

The NFRs are classified in 4 main concepts by \cite{CysneirosLN01}. The
classification uses the \textit{quality properties}. The properties are:
\textit{performance; security; cost;} and \textit{usability}. Pastrana
\cite{PastranaPK11} describes an ontology based methodology and uses a NFR
classification based in some properties, most already described in other works,
however this work is the only one to use the \textit{scalability, capacity}
and \textit{precision} property values. Considering web services development,
these properties are not very frequently used, however, considering data
processing, these properties can be important in cases of large data processing
requests through services.

In a different way, Sommerville \cite{sommerville08} classifies requirements,
either functional or non-functional, in three main blocks, they are:
\textit{process, product} and \textit{external}. Also defining a
sub-classification considering the system domain.
The \textit{product} software requirements are classified as follows:
\textit{usability; reliability; safety; efficiency; performance;} and
\textit{capacity}.
   

% Based on the works presented in \cite{Cleland-HuangSZS06,Glinz05rethinkingthe},
% and considering the previous analysis of NFR, the properties highlighted are
% security, performance and reliability. Although the works have
% different focuses and the NFR classification and definition are made in
% accordance with different arguments, the more present in NFR ratings
% requirements are that ones presented in Figures \ref{fig:NRFmodel} and
% \ref{fig:proposalNRF}.


Some requirements may severely restrict the design, for example, \textit{(i)}
Keep certain functions in separate modules; \textit{(ii)} check data integrity
for critical variables; and \textit{(iii)} permit only limited communication,
are examples of restrict requirements \cite{ieee_1998}. These examples are
related with some NFR concepts as: \textit{security, reliability} and
\textit{availability}. Thus, in the context of service-based
development, it is important that non-functional requirements are described
through abstract modeling levels.
 
%    Thus, based on theses works and the
% results obteined in the systematic review, the results presented in tables
% \ref{tab:result02} and \ref{tab:result03}, we will propose a NFR model and
% classification for service based application development.
   
% \subsection{NFR Metamodel:} 
% \label{sec:servicedefinitionNFR} 


In the service-based development there is a clear difference between the
business, service and system level. The quality requirements are treated
differently in each of them. Although different nomenclatures were
presented in separate works, they have in common the concepts of
\textit{non-functional concern/requirement} and \textit{non-functional attribute}.

We notice that restrictions are usually related to use cases and functional
requirements, and in most cases, this concept is represented as a service
activity. At the service level, each service activity is related to
contracts. These contracts are grouped in policy and its rules. Policies
are directly related to more general concepts of quality, for example,
security, performance and availability policies; contracts are associated with
non-functional attributes. Although different nomenclatures with similar
concepts were presented in separate works, they have in common the concepts of
\textit{non-functional concern/requirement} and \textit{non-functional
attribute}. 

% Figure \ref{fig:NRFmodel} presents a NFR meta-model and following we
% present the description of each concept.

\begin{figure}  
\centering  
\includegraphics[width=0.99\textwidth]{chapters/state_ofthe_art/figs/contractModel.pdf}
\caption{Service-Based Non-Functional Requirement Model.}
\label{fig:NRFmodel} 
\end{figure}
 
According to the concepts analysis employed in each work, we defined the most
important that are associated with service-based development. The model
present in figure \ref{fig:NRFmodel} shows the relationship between these
concepts we consider important for quality requirements used in service-based
development, as results of the analyzed works. The concepts are:

% One requirement, whether functional or non-functional, can be represented by one
% or more use cases. For example, a paying process can be modeled through the use
% cases that represent withdrawal and deposit of money in transaction of customer
% and service provider accounts. A payment process also requires the guarantee of
% a complete transaction and data security. Thus several use cases are modeled to
% a single requirement. 

%Each concept represents:
 
\begin{itemize} 
  \item \texttt{Non-Functional (NF) Attribute -} An attribute that describes
the quality or characteristics of a functional requirement. For example
\textit{confidentiality} and \textit{privacy} is an example for a non-functional
attribute for the functional requirement \textit{user registration}.
  \item \texttt{Non-Functional (NF) Requirement -} A group of semantically
correlated non-functional attributes (NFA). For example, \textit{security} is
an NF Requirement that comprises attributes such as \textit{confidentiality}
and \textit{integrity}. 
  \item \texttt{Constraint -} A constraint prevents the system
  from achieving more of its goal. With the definition of constraints, the
  system  can be more robust, and unexpected problems can be solved before it
  happens. For example, in a banking system, the customer can only withdraw
  money if you have balance in the account.
    \item \texttt{Constraint Type -} Represents the types of restrictions
  constraints expressed in the meta-model are business and data (*value) constraints. When
  modeling a system requirement the analyst can identify if there are restrictions on
  business, or data, or both. 
  \item \texttt{Contract -} Is the formalization of obligations (requires) and
  benefits (ensures) of a function, service activity or component.
  The following questions can be used to define contracts: \textit{What does it
  expect? What does it guarantee?} Contract are crucial to software correctness that they should be part of the design process. A
  interface is a kind of contract.
  \item \texttt{Exceptional Behaviour -} Are alternative execution paths if
  any condition or restriction is not respected. For example, if a User's password
  is not correct after three attempts, the User account is locked for security.
  \item \texttt{Policy -} A policy is a set of rules applied to a particular
  scope. This scope can be defined as an action, an activity, a function or a
  workflow. A policy is a composition of contracts applied to a non-functional
  application requirement. For example, a security policy of a system constraint
  includes authentication, access, data privacy, and so on.
 \item \texttt{Use Case -} Represents a behavior that can be executed
in order to realize (parts of) the \textit{Functional Requirement}.
  \item \texttt{Composite Use Case -} Represents a set of actions performed by
  the system to carry out part of a business service, which can be broken down
  into different use cases, which may in turn be basic or composite.
  \item \texttt{Requirement -} A requirement is a super type for functional and
  non-functional requirements. Thus, the use cases can be related to both types
  of requirements.
  \item \texttt{Functional Requirement -} Defines a function of a software
  system or its component. Functional requirements may be calculations,
  technical details, data manipulation and processing and other specific
  functionality that define what a system is supposed to do.  
\end{itemize}

\bigskip
\bigskip

One \textit{requirement}, whether functional or non-functional, can be
represented by one or more use cases. And each use case represents a \textit{service
activity}. For example, a paying process can be modeled through the use cases
that represent withdrawal and deposit of money in transaction of customer and service provider accounts. A payment process also requires the guarantee of
a complete transaction and data security. Thus several use cases are modeled to
a single requirement.
% 
% A composite use case is a type of use case. This type of
% use case abstracts a more macro function, and may contain extra functions to be
% performed so that the process is complete. For example, to publish a song, you
% must choose which song you want to publish, , authenticate to twitter or facebook,
% so that the music you're listening is published. We consider this type of use
% case, a use case compound.

Each use case has many \textit{constraints}, these can be \textit{business} or
\textit{value} constraints. \textit{Business constraints} are restriction on
functions and how they may be implemented. The \textit{value constraints} are restrictions on
the service interface, which the desired values for input and output data. Each
constraint is associated with NFAs.

A \textit{contract} is a set of constraints for the same function. For example,
a contract for the payment operation, by credit card. That the value amount should
not be less than 10 euros and the user should always receive a purchase
confirmation by email or by phone message. This set of restrictions will be
composed into a single contract for the payment transaction. These constraints
are also associated with non-functional attributes, e.g., reliability,
transactions and data privacy card.

An \textit{exceptional behavior} happens when a contract is breached. When this
happens a new function is called or the processing is stopped.  This entity represents the
alternative paths during the use case modeling. For example, if the bank
does not authorize the payment, the system or service offers alternative forms
of payment such as a bank bill or purchase via PayPal.

Finally a \textit{policy} groups similar contract. For example, contracts for
the application safety, or contracts on the system performance are grouped as
policies. For example, payment and authentication contracts are
grouped into security policy. As well as contracts that require a time-out
processing, are grouped into performance policy. Each policy is associated with
a type of non-functional requirement. Each non-functional requirement is
associated with one or more non-functional attributes. 

\bigskip
\bigskip

Considering the hierarchy's analysis of non-functional requirements described in
most studies, we present a synthesis of what we identified to be most
appropriate to be used for non-functional requirement modeling for
service-based applications. The NFRs have been classified into three levels,
\textit{business, services} and \textit{systems}. According to each modeling
level, non-functional requirements are being refined from the business level to
system level.

 Similar classification can be seen in\cite{Yeom2006}. However, in
 \cite{Yeom2006} NFRs are not applied on data, but in functions and
 service performance. We consider that is important to classify the
 requirements in respect of business and data (value) restriction, because web
 services can be executed in different contexts. 

% \begin{figure}
% \centering
% \includegraphics[width=.6\textwidth]{chapters/state_ofthe_art/figs/desenho.pdf}%{figs/NFRClassification.png}
% \caption{Non-functional requirements classification.}
% \label{fig:proposalNRF}
% \end{figure}

Table \ref{tab:result04} shows the NFR classification we propose, while
figure \ref{fig:NRFmodel} presents the NFR concepts for reliable service-based
application modeling.



\begin{table}[ht!]
\centering
%\scriptsize
\begin{tabular}{l|l|l}
  \hline 
  \hline
   \textbf{Modeling Level} & \textbf{\textit{Concept / Notation}} & \textbf{\textit{NFR / NFA}}  
   \\
  \hline
  \hline  
  Business Level & Constraint  & Business Constraint,    
 \\  
  &   & Value Constraint\\
  \hline   
   &  & Integrity, Transaction,  \\
   &  & Accessibility, Encryption, \\
   &  & Cost, Time Constraint, \\
  Service Level & Contract & Encryption, Platform, \\
   &  & Privacy, Authentication, \\
   &  & Resource, Capacity, \\
   &  & Privacy, Confidentiability 
   \\  \hline
   &  & Security, Performance,\\ 
   & & Interoperability, Scalability,\\
  System Level & Policy & Reliability, Usability,\\
   & & Transactional Behaviour,\\
   & & Availability \\ 
   \hline
  \hline  
\end{tabular}
\caption{Non-Functional Requirements Classification.}
\label{tab:result04}
\end{table} 


%>>>PAREI AQUI A REVISAO, INCLUINDO INGLES.  


% The NFR classification model presented in the figure \ref{fig:NRFmodel} is
% consistent with the properties discussed in the systematic review. Were
% considered the NFR most commonly presented and checked to the development of
% web services applications.



% For instance, considering the structure and the concepts of modeling engineering
% (MDD and MDA), the non-functional requirements can be refined from CIM level to
% PSM level, being observed the specific areas of each application.
%  
  
% 
% \subsubsection{Business NFR Definition:}

At the business modeling level, non-functional requirements are classified
into business restrictions, or data restriction. We have adopted, \textit{business} and \textit{value}
constraints to address the more abstract levels of restrictions in business
modeling. Follow we describe both concepts for modeling NFR in business level.

% We have adopted this
% nomenclature for the fact that in business modeling level, the
% granularity is coarse. However, at this modeling level it is possible to
% identify if there are any restriction and if this restriction is over business
% functions or data. Thus

\begin{itemize}
  \item \texttt{Business Constraint -} Some rules for business or system
  development in terms of resource availability, interoperability, performance,
  dependencies, timescales, or some other factor. For a business modeling it is
  important to set out in detail the constraints that are likely to act as
  limits on business activity. Thus, \textit{Business Constraint}
  are restrictions over business activities that perform business functions.
  \item \texttt{Value Constraint -} Define limits on the values which it can
  represent. It is often useful to be able to constrain the values which an
  element can take, perhaps to ensure that messages conform to business rules.
  This concept describes how value constraints can be added to a simple type in
  order to constrain the values of all elements based on it. In the context of
  services, value constraint are restrictions on the data on service calls
  (input and output values), which range of values is allowed. This can be
  applied to authentication policies, access control, data integrity, cost of
  services, privacy, and other factors. 
\end{itemize}  

% % \subsubsection{Service NFR Definition:}    
% 
% The relationship between the concepts in business and service levels are
% presented below:
%  
% \begin{itemize}
%   \item Business constraint:
% 	\begin{itemize}
%   		\item Security; Performance; Availability; Interoperability; and Usability.
% 	\end{itemize}
%   \item Value constraint:
% 	\begin{itemize}
%   		\item Security; and Reliability.
% 	\end{itemize}
% \end{itemize}
  
% \subsubsection{System NFR Definition:}  

% Yeom et al. \cite{Yeom2006} describes some concepts for NFR in the system
% modeling. Some of these concepts is adapted for our context and proposal of NFR
% classification for web service modeling process. 
At the service level, the non-functional properties will be guaranteed upon
implementation of the service requirements. Following we describe the
non-functional properties to the service level
  
\begin{itemize} 

  \item \texttt{Conformity -} This is a factor to evaluate to which degree
  the standard technology of web services are conformed. You can have functions
  that perform this property, when necessary for customer's service.
  \item \texttt{Time constraint -} Is the property of the
  execution time of a particular service, and its possible relationship to time
  with other services. Depending on the context of software development, some
  services must be performed in obedience to rules and time constraints. Thus
  this type of property is directly related to services performance and
  availability, in more abstract level.  
  \item \texttt{Capacity -} Is the ability to perform a data volume
  steadily. In the context of services, this property is the guarantee of a
  particular service can process a volume of data or requests for a smooth and
  steady manner. 
  \item \texttt{Transaction -} It is designed to maintain a
   system in consistent state, by ensuring that any operations carried out on
   the system that are interdependent are either all completed successfully or
   all canceled successfully. Transaction also can be defined as an activity or
   request. Orders, purchases, changes, additions and deletions are typical
   business transactions stored in the computer. This type of property is widely
   used in various types of applications and is constantly necessary to develop
   transactional services, such as money transfer services to bank accounts. 
  \item \texttt{Cost -} To run a service, can be measured in many ways,
  time, bandwidth and money are some examples. The cost is directly related
  with the performance and security services.  The service cost 
  modeling is sometimes necessary. Thus, this type of requirement is
  necessary for modeling services, and are presented in our meta-model (Figure
  \ref{fig:NRFmodel}). 
  \item \texttt{Privacy -} Information privacy, or data privacy is the
  relationship between collection of data, technology and the legal and
  political issues surrounding them. The challenge in data privacy is to share
  data while protecting personally identifiable information. Privacy in use of
  web services is the ability of the service must have to preserve the data and
  user information. 
  \item \texttt{Authentication -} Considering web development, 
  authentication web service is like a door on your house. It needs to be wide
  enough to allow people to enter, but only if they've knocked first. Getting
  away from the cutesy analogies, authentication is the process of making sure
  that the person who is asking to use the web service is really the person that
  they claim to be. This NFR concept is important in the development phase, and
  have to be a robust modeling. 
  \item \texttt{Accessibility -} It represents the quality aspect of a web
  service related with the degree to which it is capable of serving a
 request. It is the chance of a successful service instantiation at a point in
 time .
  \item \texttt{Access control -} Access control is, in reality, an everyday
  task. A lock on a car door is essentially a form of access control. A
  PIN on an bank system is another means of access control. Access control
  refers to exerting control over who can interact with a resource. The resource
  can be a computer-based information system, a service or a database. Typically
  the access point is a door. An access control door can contain
  several elements and this kind of service may control what the user can
  actually access. 
  \item \texttt{Confidentiability -} It is an ethical principle associated with
  several professions. In computer science, confidentiality ensure that
  information is not accessed by unauthorized persons. The private data is
  accessed only by users owners. confidentiality in applications is a growing
  demand for web applications.
  \item \texttt{Integrity -} It represents the ability of the web service to
  maintain the correctness of the interaction which is ensured by the proper
  execution of a web service transaction. This idea is also expressed in as
  transaction support related attribute of QoS. 
  \item \texttt{Resource -} A computer resource is any physical or virtual
  component of limited availability within a computer or information management
  system. Computer resources include means for input, processing, output,
  communication, and storage. In the context of web services, an appeal may be
  given generally related to a particular service. It can be any input, output
  or stored data somewhere. Define constraints with this property is to define
  rules on data that may be necessary for the service user. 
    \item \texttt{Platform -} Web services platform management is the management
  of the platform on which a web service is installed and provided. It is
 available as long as such a platform is with the standard management interface
 \cite{Yeom2006}.
\end{itemize} 


The service base application's non-functional requirements are a set of
properties related to activities that need to be performed in the system to carry out a
service activities and business service. So, the quality properties at the
system level represent a behaviour that is part of the workflow needed, such as
usability, security, reliability, availability, and so on. Following these
properties are defined.

\begin{itemize}
  \item \texttt{Usability -} ISO defines usability as ``\textit{The extent to which a
  product can be used by specified users to achieve specified goals with
  effectiveness, efficiency, and satisfaction in a specified context of use}''. 
  Usability also refers to methods for improving ease-of-use during the design
  process. In the context of services, usability can mean how efficient and
  easy to access a service is and whether it satisfies the needs of those who
  are invoking this service.
  \item \texttt{Interoperability -} Is a property referring to
  the ability of diverse systems and organizations to work together. If two or
  more systems are capable of communicating and exchanging data, they are
  exhibiting syntactic interoperability. According to ISO interoperability is
  defined as ``\textit{The capability to communicate, execute functions, or transfer
  data among various functional units in a manner that requires the user to have
  little or no knowledge of the unique characteristics of those units}''. In the
  context of services, interoperability can mean that the services have capacity
  to communicate with each other and execute other services functions. 
%   The term
%   \textit{choreography} can simplify the understanding of interoperability
%   between services. 
  \item \texttt{Reliability -} Is the ability of a
  service or component to perform its required functions under stated conditions
  for a specified period of time. The concept of reliability has different
  applications in different areas. Applied to web services, reliability is the
  ability of the service that is running be correct. It is also important
  that the data presented are consistent with the expected result. Services
  reliability depend of user view and the context it were implemented.
  \item \texttt{Availability -}  Is the proportion of time a service 
  is in a functioning condition. This is often described as a mission capable
  rate. Availability of web services, is the probability of a service call 
  be successful, given a specific time. Availability of a service/system over
  its life-cycle is typically measured as a factor of its reliability.
  \item \texttt{Performance -} Refers to the service quality product as seen by
  the customer. As the performance, in most cases, depends on network,
  in the context of web services, performance is how fast the service can be
  executed in accordance with the needs of the user.
  \item \texttt{Security -} Security as a form of protection are structures and
  processes that provide or improve security as a condition. Security of data is
  the means of ensuring that data is kept safe from corruption and that access to it
  is suitably controlled. But security also means protecting information and
  information systems from unauthorized access, use, disclosure, disruption,
  modification, perusal, inspection, recording or destruction. In the context of
  security services, all these meanings are included as a definition for web
  services security. 
\end{itemize}


The relationship between non-functional requirements and attributes help
identify groups of restrictions and contracts to develop specific policies. The
level of service shows non-functional requirements, and system level presents a
finer granularity, describing the non-functional attributes. Thus, a set of
contracts that are related to the same attribute form specific policies for the
system.
 
The relationship between the concepts in service and system levels are
presented below:

\begin{itemize}
  \item Security:
	\begin{itemize}
  		\item Access control; Transaction; Privacy; Cost; Authentication;
  		Integrity; and Confidentiability.
	\end{itemize}
  \item Performance:
	\begin{itemize}
  		\item Time constraint; Capacity; and Transaction.
	\end{itemize}
	\item Availability:
	\begin{itemize}
  		\item Capacity; and Time constraint.
	\end{itemize}
	\item Interoperability:
	\begin{itemize}
  		\item Conformability; and Platform.
	\end{itemize}
	\item Usability: 
	\begin{itemize}
  		\item Accessibility; and Platform.
	\end{itemize}
	\item Reliability:
	\begin{itemize}
  		\item Access control; Confidentiability; Accessibility; Integrity; and
  		Resource.
	\end{itemize}
\end{itemize}

We consider \textit{security, performance, availability, interoperability,
usability} and \textit{reliability} as NFRs, and we consider as NFAs the other
concepts that are related to each NFR, such as, \textit{access control, time
constraint, privacy, accessibility} and so on.

% \begin{figure} 
% \centering
% \includegraphics[width=.7\textwidth]{figs/PiSODM.png}
% \caption{Non-functional requirements for PiSOD-M Methodology.}
% \label{fig:PiSODM}
% \end{figure} 

% Considering the structure and the concepts (figure \ref{fig:PiSODM}) of PiSOD-M,
% the non-functional requirements will being refined from CIM level to PSM level,
% being observed the specific areas of each application.
 

%%%-----------------------------------------
%%% Conclusions
%%%-----------------------------------------
\subsection{Conclusions}  
\label{sec:conclusions}


  
There are some other works on web service development and reliable
systems, however were not collected doing the SLR research. Some works related with service-oriented
development have presented that the impact of the service-oriented
computing paradigm, the quality guarantees on software development and the
way in which systems can be constructed have been growing up, however there are
still few approaches facilitating software development based on non functional
properties, specially on web service oriented development. In spite of the
variety of tools, there is not (yet) a consensus on a software process methodology for
web services, spite a large amount of work already published on the subject 
\cite{PapazoglouH06,Papazoglou03,cdl2006,MilanovicM06,FeuerlichtM05,Ramollari_asurvey,somet2005}.
In order to develop and use such a methodology, it is of paramount importance to
provide adequate descriptions of its expected capabilities and competences.  
 
Works that are directly related to this can be classified into two
types: (\textit{i}) that works that propose new approaches for non
functional properties guarantees; and (\textit{ii}) those works proposing
service-oriented development methodologies for the whole development process.
  
The proposal made by \cite{HL05TACoS} proposes \textit{Design by Contract} for
web services, that means the specification of contracts for web services on
different levels of representation contracts. It is possible to describe three
levels for specifying contracts and are them: \textit{implementation level,
XML level} and \textit{model level}. Design by Contract applied to web services allow verification services
web through the use runtime checkers, before the deployment, such as
\textit{jmlrac} \cite{LeavensCCRC02}, adding behavioral information to the 
specification of services. These behavioral data are described by JML
\cite{LeavensCCRC02}, for example.

CDL (\textit{Contract Definition Language}) \cite{cdl2006} is a XML-based
description language, whose purpose is to describe contracts for services. The
development based on CDL offers an architecture framework, design standards and
methodology \cite{MilanovicM05,Milanovic05,Milanovic06,MilanovicM06}, that can
be easy understood and applied to the development of real applications. The
greatest difficulty encountered in the use of CDL is that the language only
represents contracts for services. Its specification is generated after several 
B \cite{AbrialLNSS91} machines refinements that describe the services and their
compositions. 

% Papazoglou \textit{et al} \cite{PapazoglouH06} propose a methodologie that is
% based on the SOA extension. This work defines a service
% oriented business process development methodology with phases for business process
% development. The whole life-cycle is based on six phases, they are: planning, analysis and design,
% construction and testing, provisioning, deployment, and execution
% and monitoring. This proposal has as focus only the development
% phase and does not define specific development models, however
% describes the activities sequence needed to services develop.
% 
% IBM proposes a methodology for the development of SOA
% solutions, called SOMA \cite{soma}. SOMA defines a life-cycle with seven
% phases: business modelling and transformation, solution management, identification,
% specification, realization, implementation and deployment monitoring
% and management.To assist the SOMA development is necessary to use the tools
% proposed by IBM, which makes the process very expensive for the dependence of
% these tools. 

Unlike the analysis of works presented in this section, 
we propose a meta-model for NFR modeling and a NFR classification
(business, service and system modeling levels) for reliable service-based
development.


\section{Methodologies for Service-Based Development}
\label{sec:metodologies}


In this section, we present an analysis of methodologies for service-oriented
development, which will be described highlighting its key features, as well as
their contributions and limitations when used in a development process. 

We defined 5 research questions to guide our analysis about methodologies for
reliable development. The questions are closely related to service-based
systems. The criteria used for evaluation and comparison are:



\begin{itemize} 

 \item \textbf{\texttt{$RQ_1$:}} What is the methodology's scope?
 	\begin{itemize}
	  \item \textit{This item will review the
  proposed scope of the analyzed methodologies, which is the major phases and
  what is the purpose of each particular phase in the context of the project and
  service-oriented development.}
	\end{itemize}
  \item \textbf{\texttt{$RQ_2$:}} Is there any modeling notation? How the
  methodology define the development process considering the notation used?
  \begin{itemize}
	  \item \textit{There are several notations and
  diagrams that can be used to describe applications. This item describes which
  notation is used by the methodology for the design of its
  models, e.g., MDA, UML, SysML, etc.}
	\end{itemize}	
  \item \textbf{\texttt{$RQ_3$:}} Does the methodology use any formalism?
  If so, What is the formalism used for service specification? 
\begin{itemize}
	  \item \textit{In this item
  is analyzed if the methodology proposes the use of any formalism to specify
  the services, their compositions and iterations.}
	\end{itemize}  
  \item \textbf{\texttt{$RQ_4$:}} What is the approach to service description?
\begin{itemize}
	  \item \textit{In this
  section analyzes how the various methodologies build and deploy services and
  their compositions. Thus, the aim is to highlight the differences in the
  systems developing processes in each analyzed approach.     }
	\end{itemize}
	  \item \textbf{\texttt{$RQ_5$:}} What are the proposed methodology models?
	\begin{itemize}
	  \item \textit{Each development methodologies
  analyzed defines a set of models for the design of
  information system. This item discusses the proposed models by each
  methodologies for the specification of system behavior and modeling of
  high-level business.    }
	\end{itemize} 
\end{itemize}


% \begin{enumerate}
%   \item \textbf{\textit{Methodology's scope:}} This item will review the
%   proposed scope of the analyzed methodologies, which is the major phases and
%   what is the purpose of each particular phase in the context of the project and
%   service-oriented development.
%   \item \textbf{\textit{Proposed models:}} Each development methodologies
%   analyzed defines a set of models for the design of
%   information system. This item discusses the proposed models by each
%   methodologies for the specification of system behavior and modeling of
%   high-level business.    
%   \item \textbf{\textit{Modeling notation:}} There are several notations and
%   diagrams that can be used to describe applications. This item describes which
%   notation is used by the methodology for the design of its
%   models, \textit{e.g.} MDA, UML, SysML, etc.
%   \item \textbf{\textit{Formalism used for service specification:}} In this item
%   is analyzed if the methodology proposes the use of any formalism to specify
%   the services, their compositions and iterations.
%   \item \textbf{\textit{What is the approach to service description?:}} In this
%   section analyzes how the various methodologies build and deploy services and
%   their compositions. Thus, the aim is to highlight the differences in the
%   systems developing processes in each analized approach.     
% \end{enumerate}  

Allied with the research questions, we also compared the MDA models 
proposed by different methodologies. So, it is possible to have a clearer
view of modeling levels that are proposed by each approach.

In general, for service-based systems, there is no specific
method to conduct the development process. With the analysis, we can identify
how these methodologies define activities and models to design reliable
services, as well as the whole system.

\subsection{Concepts and Works}
\label{subsec:methodology_concepts}

Over the last few years, a number of approaches have been devised for the development of web services.
These approaches range from (just) the proposal of new languages for web service
descriptions~\cite{bpel03, MPC08, wscl02, Martin04,SBS04} to the (more complex)
combination of techniques to support parts of the development cycle of this kind
of software~\cite{lipari2007,BianculliGSBG07}. In general, the focus of these
approaches is to solve specific problems, like the support for transactions or
QoS, in order to improve security and reliability for this kind of application.
Some proposals address similar problems related to service composition, such as
workflow definition~\cite{AalstHKB03,MuP06} or semantic equivalence between
services~\cite{BHM06}. The proposed solutions come from many communities in the
Computer Sciences, including those of Theoretical Computer
Science~\cite{SBS04,VA05,HamadiB03,AlH01,GGP08}, Software
Engineering~\cite{burdy:05,AalstHKB03,Aal03,choreoWG,MendesPDB09}, Programming
Languages~\cite{MPC08,bpel03} and Databases~\cite{PiresBM02,ABM01}.
However, in spite of the variety of tools, there is not (yet) a consensus on a software
process methodology for web services. In order to develop and use such a
methodology, it is of paramount importance to provide adequate descriptions of
its expected capabilities and competences.

New proposals for web technology such as XML, web services, business process
management and semantic web have been promoted an evolution of
techniques and  extensions for web based development. Thus, there
are new methodologies that address the service-based development towards a
standard or a new way to develop trust service applications. The main
methodologies analyzed were: SOD-M \cite{valeriaThesis} and SOMF \cite{somf}
representing the model based development for web services; S-Cube
\cite{scube2010book} representing the business processes and service-based
development; as well as SOMA \cite{soma} that is a methodology described by IBM
for SOA solutions; Extended SOA \cite{PapazoglouH06} merges RUP and BPM
concepts for service modeling; DEVISE \cite{Dhyanesh003} is a methodology
which focus on building services-based infrastructure for collaborative enterprises;
Furthermore, there have been other proposals, such as the model WIED \cite{TongrungrojanaL04} that acts as a bridge between
business modeling and design models; and traditional approaches for software
engineering \cite{sommerville08} being applied to service-based development.

\bigskip
\bigskip

SOD-M (Service-Oriented Development Method) \cite{CastroMV11} proposes a
service-oriented approach and model-based development for web systems. The
method is based on concepts that are necessary for modeling service-oriented
applications. The main feature of SOD-M is to provide models and standards for
the construction of information systems based on services. SOD-M has focused
primarily on the development of the systems behavioral characteristics,
setting standards for the construction of business models from high-level of
modelling. The approach describes and presents three different models in
MDA ( \textit{Model Driven Architecture}) ~\cite{miller} architecture levels: CIM
(\textit{Computational Independent Models}), PIM (\textit{Platform
Independent Models}) and PSM (\textit{Platform Specific Models}).

At the CIM level, 2 models are defined, they are: \textit{value model}
~\cite{Gordijn02valuebased} and a \textit{BPMN model};
In the PIM and PSM levels are used DSL models for service orientation. The
PIM-level models are: \textit{use case model, extended use case model, process
model of service} and \textit{service composition model}, and for the PSM level,
the model are: \textit{web service interface model}, \textit{extended
 composition service model} and \textit{business logic model}. 
 
The \textit{value} model is a business model that describes a business case as
a set of values and value activities shared by business actors. The
\textit{BPMN} model or business process model is used to describe the business
process related to the environment which the system will run. These two models
represent the independent aspects of computing and they are described in the
more abstract modeling level.

The \textit{use case} model is used to represent the business services
to be implemented by the system, while the \textit{extended use case} model is a
behavioral model, but to model the system features as a way to implement the
business services. The \textit{service process} model describes the set of
activities that must be performed on the system to implement a business service.
Finally, the \textit{service composition} model represents the full flow of
business system. This model is an extension of the service process model,
however, in more detail.

In SOD-M, the PIM level models the entire structure of the application flow,
while, the PSM level provides transformations towards more specific platforms.

The methodology provides models transformations in all levels,
\textit{CIM-to-PIM, PIM-to-PIM} and \textit{PIM-to-PSM} transformations. From an
abstract model at CIM level, it is possible to realize transformation until the
PSM level. Therefore, it is necessary follow the process activities 
described by the methodology. The model to model transformations are made using
ATL \cite{atl_manual} language.

SOD-M defines a set of concepts according to two points of view:
\textit{(i)} \textit{business}, focusing on the characteristics and requirements
of the business and \textit{(ii)} \textit{system requirements}, focusing on
features and processes to be implemented in order to meet the requirements of
business. SOD-M aims to make easy the design of service-oriented
applications, as well as its implementation using current technologies.

% \begin{figure}[ht]  
% \centering
% 
% \includegraphics[width=0.8\textwidth]{figs/sodmConcepts.png}
% 
% \caption{SOD-M Concepts Meta-model\cite{CastroMV11}.} 
% \label{fig:sodmConcepts}
% \end{figure}

The basis of SOD-M is a set of concepts which guides all
development, including transformation between models. The concepts are
represented through a meta-model. This meta-model describes concepts of both the
business and system view.

This methodology provides a framework for the development of
service-oriented applications with models that can express so
clear the whole process of services-based applications. However, this
methodology has not support to describe and model non-functional
requirements. There are any component model that could express the property of
non-functional requirements, such as security, performance or availability of
services.

\bigskip
\bigskip

S-Cube Framework \cite{scube2010book} is an European proposal, in which is
proposed an integrated structure for the  development of applications for
service-based systems. 

S-Cube offers three central areas to the development of services:
\textit{Business Process Management, Composition and Coordination of
Services; and Infrastructure}. These areas are the backbone of the 
framework that are directly linked to three other areas for support
systems development, they are: \textit{Engineering and Software Design;
Monitoring; and Security and Software Quality}.

This methodology aims to guide the development of applications and describes
some essential activities, such as \textit{(i) description of business objectives},
\textit{(ii) domain assumptions defining}, which are
pre-conditions to be met for a particular application domain, \textit{(iii)
description of domain}, and finally \textit{(iv) description of scenarios for
each domain}.

The S-Cube methodology goal is to provide a non-exhaustive list of rules
to description of service. Some steps must be taken to
requirements specification. 

% The steps are:
% 
% \begin{enumerate}
%   \item The terms used for describing the scenarios, identification
%   of business goals and domain assumptions must be
%     described in a glossary, and they must be related with the domain model;
%    \item The entities identified in the domain model are used in the
%     scenarios, or in some business goals or description of the domain assumptions;
%    \item All actors that were identified in the scenarios also appear on
%     description of each context;
%    \item For each scenario there must be at least one business goal
%     connected and vice-versa;
%    \item Scenarios and business goals are not overlapping. However, it is
%     possible to establish relationships, provided they are well identified, as
% well as the relationships. 
% \end{enumerate}

The S-Cube framework provides activities in various service-oriented
development areas, however, is still required to apply its
concepts in real case studies to give an idea of its application, given
the fact that its structure is very complex and multidisciplinary.     


\bigskip
\bigskip

DEVISE \cite{Dhyanesh003} aims to identify the issues to be considered in
service-based design, and seeks to outline generic guidelines for addressing them. Not only does DEVISE
aid one in the design of new applications as a collection of Web Services, but
also provides a means of porting existing applications to the services-based
platform.

Conventional software engineering methodologies provide a good start at the
design process of a collaborative Web Services based application. DEVISE
prescribes adherence to a thought process that entails the division of the
design of a Web Services based collaborative application, 

\bigskip
\bigskip

SOMA (\textit{Service-Oriented Modeling and Architecture}) \cite{soma} is a
methodology described by IBM for SOA solutions. SOMA defines a seven phases
development life-cycle: \textit{business modeling and transformation; management
solution, identification, specification, realization, implementation}, and
\textit{monitoring of implementation and management}.

At each stage, different tasks are carefully defined,
such as the definition of business architecture, development of service model,
specification of services, etc. SOMA is a methodology for implementing
SOA, however an IBM-oriented applications.

% \begin{figure}[ht]  
% \centering
% 
% \includegraphics[width=0.8\textwidth]{figs/soma.png}
% 
% \caption{SOMA Methodology Structure \cite{soma}.}
% \label{fig:soma} 
% \end{figure}

SOMA conceptual model is based on an SOA architecture style that
defines an interaction model in three main parts: \textit{the service provider},
which publishes a service description and provides the implementation for the
service, \textit{consumer services}, which can use the URI for the service
description directly or can find the service description in a service register
for the call, and the \textit{service broker}, which provides and maintains a
record of services, although today the public records
are not normally used.

IBM proposes the use of IBM Rational platform for SOA developing, and other
different IBM tools that are available to analysts, software architects and
application developers. This tool is perhaps the biggest disadvantage of
applying the IBM proposal, because of the need to use different types
of tools such as IBM WebSphere and IBM Rational Software, all of them very
complex in order to develop applications. Furthermore is a high tool costs.     

\bigskip
\bigskip
   
SOMF (\textit{Service-Oriented Modeling Framework}) \cite{somf} is a 
model oriented methodology, whose specific goal is modeling
software with the best practices of software project activities and different
architectural setting that are employed during the stages of software
development. SOMF can be used to describe enterprise architectures, service-oriented
architecture (SOA) and cloud computing. SOMF offers a variety of modeling
practices and disciplines that can contribute to developing a successful
service-oriented applications.       

The SOMF structure offers a technology independent notation, focusing on
development-based services. The SOMF slogan is \textit{`` Model first,
build later!''}, which means \textit{`` Model first, implement later!''}.
Model concerns the construction of a abstract representation of a software
product, application, software component, system, or any other software asset. 

The main features of SOMF are:

\begin{enumerate}
  \item No prior knowledge of programming language or modeling tools are needed;
  \item Modeling activities are fast. Models and diagrams can be developed in
  minutes;
  \item Driven by a methodology. A methodology describes SOMF modeling
  activities and each model transformation;
  \item Model oriented. SOFM describes eight models transformations
  for development of applications;
  \item Flexible design to provide an easy development of models;
  \item Patterns oriented. The diagrams are created obeying some project
  patterns.
\end{enumerate}

The methodology's model transformations aims to
describe and refine aspects in the system development
process. The models are: \textit{discovery model, analysis model, design model,
architectural model, implementation model, quality model, operations model,
business model, governance model}. 

% These models are integrated into each
% methodology activity and in their respective phases. For service modeling, SOFM
% highlights the need of:
% 
% \begin{enumerate}
% \item Identify service relationships;
% \item  Establish message routes between consumers and providers
% services;
% \item  Provide efficient service orchestration and choreography methods;
% \item  Create service transaction and behavioral patterns;
% \item Providing solutions for deployment of services.
% \end{enumerate}

The main SOMF disadvantage is the use of an own modeling notation, 
different from those existing services notation. The methodology introduces
several new concepts and notations for modeling services and compositions during the
development phases. Along with SOMA, SOMF also focus on models to represent all
aspects of the application.

\bigskip
\bigskip

As there are specificity in service-oriented development, 
methodologies for object-oriented applications or components can not be directly
applied to services. This occurs because SOA-based development have principles and
techniques different from traditional object-oriented and components approaches.

Extended SOA has the lifecycle of web development services with focus on the
phases of \textit{analysis, design} and \textit{development}, with a centered
approaches in functional requirements.  Based with \cite{PapazoglouH06}, an
specific methodology for developing services-based is important to specify,
build, improve and customize business processes available on the Web. 

Extended SOA has a hierarchical structure for the development of web
services, where layers are defined as follows: \textit{Business (Service)
Domain, Business Processes, Business Services, Infrastructure Services,
Component-based Service Realizations} and \textit{Operational Systems}.

The methodology is partly based on other successful models and
related development, such as the Rational Unified Process (RUP),
Components-based development and Business Process Modeling (BPM). The difference
is that Extended SOA life cycle focuses on service-oriented development.

Extended SOA is based on three principles for the design and development of
services, they are: \textit{Service coupling, Cohesion of service}
and \textit{Service granularity}.

Considering service-oriented projects, it is preferable to create high-level
interfaces with high granularity to implement a complete business process,
because multiple calls of service increases network traffic.
As the services are in a cooperative environment, it is unfeasible to create
services with low granularity. It is preferable to create functions with lower
granularity in a local environment. Thus, the methodology aim is to achieve
services integration and interoperability. The Extended SOA phases are:
\textit{Planning, Analysis, Design, Implementation, Testing,
Provisioning, Implementation, Execution} and \textit{Monitor}.

% \textbf{Planning:} The planning phase determines the
% viability, nature and scope of service solution. The planning
% phase is very similar in software development methodologies, including RUP. The
% key requirement at this stage is to understand the business environment and make
% sure that all necessary controls are incorporated into the project to a
% service-oriented solution.
% 
% \textbf{Analysis:} The analysis phase examines the server-side existing
% services to understand which processes/services that already exist and what
% need to be created and implemented. 
% 
% \textbf{Design:} The service specification is a set of three
% elements of the specification, all equally important:
% \textit{structural specification, behavioral specification} and
% \textit{business specification}.
% 
% \textbf{Implementation:} The methodology implementation phase includes
% Web services development, from the service interface description to the service
% implementation definition. The methodology does not present anything new to this
% phase in the development of services web.
% 
% \textbf{Test:} The methodology proposes the conventional testing approaches,
% such as \textit{test functional, performace test, dynamic test} and
% \textit{integration test}. However, the methodology concludes that
% \textit{dynamic test} approach is more appropriate to be used to web service
% test.

\bigskip
\bigskip

Sommerville \cite{sommerville08} proposes a general approach to
applications that use web services. Its structure uses the activities of
design, development, construction and testing of web services and their
compositions. 

The main objectives described is based on the concepts of
software engineering, they are:

\begin{itemize}
  \item Software reuse, standards-based web service that provides a mechanism
  for inter-organizational computing;
  \item Use a process engineering services to produce web services reusable;
  \item Perform composition of services to facilitate and improve development of
  applications;
  \item Show how business process models can be used as basis for the design of
  service-oriented systems.
\end{itemize}

Existing approaches to software engineering has to involve the concept of
web services for software development. Service engineering
allows the development of reliable service and
reusable. Thus the entire life cycle of development will focus primarily on the
reuse of independent services. With this development we have software
\textit{reuse}. On the other hand there is the development with services. The development of
dependable software where services are the key components. By this
way we have the  software development \textit{with reuse}.

A key difference between a service and a component is that services are
independent. The components are always used with another software component. The
services come with a message-based communication, and these messages expressed
in XML, which are independent. Thus, the definition of a method must be based on
a set of principles to be followed for the development of
applications that use web services and their compositions.

A service must be designed as a abstraction that can be reused by different
systems. The main activities for service engineering are: \textit{(i)}
Identification of candidate services; \textit{(ii)} Service design; and
\textit{(iii)} Service implementation.

From the identification of system requirements, the whole project is based
on services that can be reused or implemented. From this
identification, the project is developed in order to be implemented the
services needed in the application. If the service is already available,
adapt it to current system needs.



%*********************************************************************************************************
\subsection{Analysis}
\label{sec:methodology_analisys}
%*********************************************************************************************************

The analysis is based on the items described at the beginning of this section,
which attempt to cover important aspects of service-oriented application
development. We analyze the
aspects of modeling and models proposed, which
notations are used for modeling, and what is the formalism used for
services specification. We also include the analysis of
model abstraction level in each methodology, according to the MDA
approach. We also analyze the models proposed to represent business processes
and composition services.

To complete the analysis study, we made
a summary of the main features discussed in table \ref{tab:method_analysis}.
This table shows the main differences from the methodology issues, considering
the research questions. 

\begin{sidewaystable}
\caption{Methodologies' Analysis} % title name of the table
\label{tab:method_analysis}
\centering
\begin{tabular}{l|l|l|l|l|l|l|l|l} 
\hline 
\hline

\multicolumn{2}{l|}{\multirow{2}{*}{}} &
\multicolumn{7}{|c}{\textbf{Service-Based Development Methodologies}} \\ \cline{3-9}

\multicolumn{2}{l|}{} & \textbf{SOD-M \cite{valeriaThesis}} & \textbf{S-Cube
\cite{scube2010book}} & \textbf{SOMA \cite{soma}} & \textbf{SOMF \cite{somf}} &
\textbf{DEVISE \cite{Dhyanesh003}} & \textbf{Extended}
& \textbf{Traditional} \\
\multicolumn{2}{l|}{} &  &  &  &  &
 & \textbf{SOA \cite{PapazoglouH06}}
& \textbf{Method \cite{sommerville08}} \\
\hline
 
\multicolumn{2}{l|}{ \textbf{Methodology's Scope}} & \textit{complete} &
 \textit{complete} & \textit{complete} & \textit{analyse,} & \textit{complete} &
 \textit{complete} &  \textit{analyse, design} \\
 
 \multicolumn{2}{l|}{} &  &  & & \textit{design} & & & 
 \textit{implementation} \\
 
 \hline
 
 \multicolumn{2}{l|}{\textbf{Methodology Models}} & \textit{e-value, BPMN,}  &
 \textit{UML} &\textit{UML} & \textit{own} &  \textit{UML} &  \textit{BPEL, UML} & 
 \textit{UML} \\ 
 \multicolumn{2}{l|}{} & \textit{UML}  &  & & \textit{notation} & & & \\

 \hline
 
 \multicolumn{2}{l|}{\textbf{Formalism Used}} & \textit{N/A}  & \textit{N/A}
 &\textit{N/A} & \textit{N/A} &  \textit{N/A} &  \textit{N/A} & 
 \textit{N/A} \\ 
 
 \hline
 
\multicolumn{2}{l|}{ \textbf{Service}} & \textit{no}  & \textit{no}
 &\textit{no} & \textit{no} &  \textit{no} &  \textit{no} & 
 \textit{no} \\
\multicolumn{2}{l|}{\textbf{Specification}} &  & & &  &   &   & \\ \hline
\multirow{4}{*}{\begin{sideways}\textbf{Models}\end{sideways}} &
\textbf{NFR } & \textit{no} & \textit{yes} &\textit{no}  &\textit{yes}
&\textit{no} & \textit{no} & \textit{no} \\ \cline{2-9}
& \textbf{Business } &\textit{yes} &\textit{yes} & \textit{no}&
\textit{yes}&\textit{yes} &\textit{yes} &\textit{yes}\\\cline{2-9}
 & \textbf{Use Case } &\textit{yes} &\textit{yes} & \textit{yes}& \textit{yes}&
\textit{yes} & \textit{yes}& \textit{yes}\\ \cline{2-9}
& \textbf{Service Composition } & \textit{yes}& \textit{yes}& \textit{yes}&
\textit{yes}& \textit{no}&\textit{yes} &\textit{yes}\\\hline
%& \textbf{PSM} & & & & & & &.\\ \hline
\multirow{3}{*}{\begin{sideways}\textbf{MDA}\end{sideways}} & \textbf{Abstract
Level} & \textit{CIM, PIM, PSM} &\textit{N/A} &\textit{CIM, PIM} & \textit{N/A}
&\textit{N/A} &\textit{CIM, PIM, PSM} &\textit{N/A} \\ \cline{2-9}

& \textbf{Model}&\textit{yes} & \textit{no}
&\textit{ yes} & \textit{no} & \textit{no} & \textit{yes} & \textit{no}\\

& \textbf{Transformation}& & 
& &  &  & & \\
\hline
\hline
\end{tabular}
\end{sidewaystable}


S-Cube and SOMF methodologies provide concepts for modeling 
non-functional requirements, however they have specificities that hinder the
development. SOMF has a self notation for modeling and does not have a
environment to assist the development process, thus hindering the design of
models and their transformations. The S-Cube is a complex framework that is
still being consolidated, it is not yet feasible because its use is still under
validation. 

The extended SOA methodology and the use of traditional methods for the
development of service applications seems interesting, because
the developer has a vision of the whole development structure. The
disadvantage is they do not provide a way, such as WSDL or 
formalism, to represent the service specification. They also do not provide a
tool for development support. Another disadvantage of traditional methods
applied to service-based development is the fact  these methods do not have the
focus in the development of services.

Such as S-Cube methodology, SOD-M and SOMA provide a robust process and
concepts for service-oriented development. Both methodologies have focused on
the model driven development. However, these methods do not provide models for
representing  non-functional properties. S-Cube uses UML to represent project
models, covering the full development life-cycle, describing each service and their compositions. The 
S-Cube structure seems to be quite extensive and complete, however, S-Cube does
not provide formalism for specifying service composition.     

None of the analyzed methods uses a formalism for he description and
specification of services. Most of them uses UML or some UML extension
for model representation, and only SOMF approach does not address the full
life-cycle of development, restricting the scope in the analysis and design
phases.

Considering the methodology analysis, we conclude that there are any
approach that address modeling non-functional aspects as the methodology basis.
Several methods proposes particular aspects to improve the service-based
development. Some proposals consider the whole life-cycle, however, do not
consider non-functional aspects that should be designed when
developing applications that provide and use web services.

Some development methodologies have worked
with the MDA approach, defining models for the different levels of abstraction
of this architecture and in some cases, such as SOD-M, DEVISE and SOMA, defining
rules for automatic transformation between them. SOD-M is a method
for service-based development using MDA, and thus define models at CIM, PIM and
PSM of the proposed architecture.
However, among the methods examined, deserves highlight the SOD-M methodology.


To conclude, based on our analysis and the results presented in the table
\ref{tab:method_analysis}, a interesting methodology for reliable service-based
development may address: \textit{(i)}) the definition of a service-oriented
approach-oriented models for the development of applications, \textit{(ii)}
model the definition specific for representing non-functional properties and the
use of UML for this, \textit{(iii)} integration of the proposed method in the
context of MDA architecture providing the representation of the various
applications levels, CIM, PIM and PSM, and \textit{(iv)} the transformation
between models with MDA focus on quality requirements.


%\subsection{Proposed Concepts}

%********************************************************************************************************* 
\subsection{Conclusions}
%*********************************************************************************************************
We reviewed the main methodologies for service-based development, with
particular emphasis on models proposed for these development of behavioral
aspect. We analyze other general aspects of these methodologies as its paradigm
of development, UML and formalism used, and if the method considered an MDA-based
development. In this case we have studied the main techniques and methods proposed for
  non-functional requirements modeling, business process modeling and web
  service composition modeling.

In general, after reviewing the current research works related
with the problem of service-oriented development, we could obtain
some conclusion. There are no proposals that define a service-oriented approach
for the complete development of systems, considering non-functional
requirements. Although many efforts that have been made to support the new
technological proposals for the Web such as web services, in general, these
methodologies continue to maintain their processes and traditional software
engineering approaches.

The comparative study of such methodological approaches for service development
will be the basis for the aspects and contributions of the method we propose in
this work.

 
%********************************************************************************************************* 
\section{Conclusions}
\label{sec:stateofart_conclusion}
%*********************************************************************************************************

This chapter presents a review of related approaches
service-oriented development of applications. We consider two important
topics for works analysis: \textit{(i)} non-functional requirements and
\textit{(ii)} methodologies for service-based development. The were were
grouped according to their characteristics, and analyzed in each context of
application.

Our work aims to propose a approaches that address the reliable
service-based development, uses service composition, and
ensure non-functional aspects. Thus, this analysis have considered the issue
addressed to compare their similarities and the different aspects between them.
Non-functional aspects are treated in a special cases by some approaches, but
are not often considered in the whole of methodology for web service
development.

After the results of this analysis, through the following chapters we
will describe our proposal of a service-based  methodology focused on
non-functional aspects description and modeling. For this, we use model-based
development (MDD) and the classification of non-functional requirements
described in this chapter, as well as the meta-model with NFR notations.     





% \begin{sidewaystable}[h]\caption{Performance After Post Filtering} % title name of the table\centering % centering table\begin{tabular}{l c c rrrrrrr} % creating 10 columns\hline\hline % inserting double-lineAudio &Audibility & Decision &\multicolumn{7}{c}{Sum of Extracted Bits}\\ [0.5ex]\hline % inserts single-line% Entering 1
% st
% row& &soft &1 & $-1$ & 1 & 1 & $-1$ & $-1$ & 1 \\[-1ex]\raisebox{1.5ex}{Police} & \raisebox{1.5ex}{5}&hard& 2 & $-4$ & 4 & 4 & $-2$ & $-4$ & 4 \\[1ex]% Entering 2
% nd
% row& &soft & 1 & $-1$ & 1 & 1 & $-1$ & $-1$ & 1 \\[-1ex]\raisebox{1.5ex}{Beethoven} & \raisebox{1.5ex}{5}& hard&8 & $-8$ & 2 & 8 & $-8$ & $-8$ & 6 \\[1ex]% Entering 3
% rd
% row& &soft & 1 & $-1$ & 1 & 1 & $-1$ & $-1$ & 1 \\[-1ex]\raisebox{1.5ex}{Metallica} & \raisebox{1.5ex}{5}& hard&4 & $-8$ & 8 & 4 & $-8$ & $-8$ & 8 \\[1ex]% [1ex] adds vertical space\hline % inserts single-line\end{tabular}\label{tab:LPer}\end{sidewaystable}
